home *** CD-ROM | disk | FTP | other *** search
Text File | 1997-09-04 | 45.6 KB | 1,189 lines
- 1 - 3. _N_e_w__s_i_n_c_e__I_R_I_X__6_._2 _T_h_i_s _s_o_f_t_w_a_r_e _i_s _i_s _u_p_w_a_r_d_s-_c_o_m_p_a_t_i_b_l_e _f_r_o_m _t_h_e _p_r_e_v_i_o_u_s_l_y _r_e_l_e_a_s_e_d _v_e_r_s_i_o_n. _A_n_y _s_u_c_h _c_o_m_p_a_t_i_b_i_l_i_t_y _p_r_o_b_l_e_m _w_o_u_l_d _b_e _a_n _i_m_p_o_r_t_a_n_t _b_u_g. _I_f _y_o_u _d_i_s_c_o_v_e_r _o_n_e, _p_l_e_a_s_e _r_e_p_o_r_t _i_t _i_m_m_e_d_i_a_t_e_l_y _s_o _i_t _c_a_n _b_e _f_i_x_e_d _A_S_A_P. _N_e_w _f_e_a_t_u_r_e_s _w_i_l_l _n_o_t _h_a_v_e _e_i_t_h_e_r _t_h_e_i_r _A_P_I _o_r _A_B_I _f_r_o_z_e_n _u_n_t_i_l _w_e _g_e_t _n_e_a_r _a _f_o_r_m_a_l _r_e_l_e_a_s_e. _I_n _t_h_e _m_e_a_n_t_i_m_e, _i_t _i_s _p_o_s_s_i_b_l_e _t_h_a_t _A_P_I _a_n_d/_o_r _A_B_I _m_a_y _c_h_a_n_g_e _a_s _w_e _g_e_t _m_o_r_e _e_x_p_e_r_i_e_n_c_e _w_i_t_h _t_h_e_s_e _n_e_w _f_e_a_t_u_r_e_s. _W_e _s_h_a_l_l _n_o_t _i_n_t_r_o_d_u_c_e _g_r_a_t_u_i_t_o_u_s _b_r_e_a_k_a_g_e, _b_u_t _w_e _a_r_e _a_l_s_o _n_o_t _y_e_t _b_o_u_n_d _b_y _c_o_m_p_a_t_i_b_i_l_i_t_y _c_o_n_s_t_r_a_i_n_t_s _i_n _o_u_r _e_f_f_o_r_t _t_o _m_a_k_e _t_h_i_s _s_o_f_t_w_a_r_e _b_e _a_s _g_o_o_d _a_s _i_t _c_a_n _b_e _b_y _r_e_l_e_a_s_e _t_i_m_e. 3.1 _S_i_g_n_i_f_i_c_a_n_t__B_u_g__F_i_x_e_s__S_i_n_c_e__I_R_I_X__6_._2 3.1.1 _l_i_b_v_k__N_o__L_o_n_g_e_r__U_s_e_s__V_k_F_o_r_m_a_t_(_) lllliiiibbbbvvvvkkkk has been changed to use its own private copy of VVVVkkkkFFFFoooorrrrmmmmaaaatttt. This prevents conflicts with any application use of VVVVkkkkFFFFoooorrrrmmmmaaaatttt. 3.1.2 _C_o_r_e _d_u_m_p _w_h_e_n _d_e_l_e_t_i_n_g _a_n _o_b_j_e_c_t _f_r_o_m _i_t_s _c_a_l_l_b_a_c_k _l_i_s_t Deleting an object from within its own executing code is, in general, a Bad Idea. Deleting a VkCallbackObject from within a callback it has called amounts to just such a problem. VkCallbackList has been fixed to that it will not itself core dump in this case, but there remains no assurance that something else in libvk will not core dump. The problem is that library code may need to use the object to do other things after the callback list has been called. 3.1.3 _V_i_e_w_k_i_t__V_i_s_u_a_l_s__H_a_n_d_l_i_n_g Viewkit had a number of places where it wrongly used default visual information. ViewKit visual handling and visual inheritance has now been entirely cleaned up. See the description of the new VkVisual class (below) for more information. 3.1.4 _V_k_S_i_m_p_l_e_W_i_n_d_o_w__W_i_n_d_o_w__S_t_a_t_e__S_e_t_t_i_n_g__a_n_d__T_r_a_c_k_i_n_g There were a number of problems with how VkSimpleWindow changed from one window state to another, and how it tracked the state. These have now been fixed so that they work and Viewkit is ICCCM-compliant, the VkSimpleWindow manual page has a much improved description of these things, and a - 2 - related new member function, getVisualState(), has been added. Affected VkSimpleWindow functions are: hide(), show(), visible(), iconify, open, iconic(), and the callback routines that handle MapNotify and UnmapNotify. The code now properly generates synthetic UnmapNotify events for the window manger. WM_HINTS.initial_state is updated whenever moving from WithdrawnState to either IconicState or NormalState. We believe that applications will be unaffected by this fix (except that some things that failed to work correctly before now will). Since the old code did not work correctly, it is possible that an application may have inadvertantly depended on a bug, and as a result will now have changed behavior. 3.2 _N_e_w__C_l_a_s_s_e_s__&__O_t_h_e_r__E_n_h_a_n_c_e_m_e_n_t_s__S_i_n_c_e__I_R_I_X__6_._2 3.2.1 _D_e_f_a_u_l_t__V_i_e_w_K_i_t__h_e_l_p__i_s__n_o_w__i_n__l_i_b_v_k The default help routines and been moved into libvk, and the help entry points are weak symbols. That means it is no longer necessary to link with libvkhelp unless you want help other than the default ViewKit help. libvkhelp still exists, so that Makefiles will work without change. However, it is empty and is no longer necessary. Help libraries contain normal (i.e. not weak) symbols. The linker will resolve references to point to the strong symbols of the added help library. To do so, the linker needs to see the strong symbols. If the additional help library is a DSO, there is no problem. The SGI help library, libhelpmsg, is now a DSO. If you are providing a help archive library of your own, you need to either convert it to a DSO or else link it with the ld option "-all". (If you are using CC to link, the option is "-Wl,-all".) If you use -_a_l_l, you probably want to turn it back off by using -_n_o_n_e after the library is loaded. 3.2.2 _n_3_2__I_m_a_g_e_s__I_n_s_t_a_l_l_e_d__B_y__D_e_f_a_u_l_t As of IRIX 6.3, this is the SGI default. - 3 - 3.2.3 _V_k_S_i_m_p_l_e_W_i_n_d_o_w_:_:_g_e_t_V_i_s_u_a_l_S_t_a_t_e_(_) getVisualState() is a new function that returns the X11 window state. This allows determining the window state with a single call. Previously the application had to combine the results of calls to visible() and iconic(), leading to confusion. 3.2.4 _V_k_P_r_o_m_p_t_D_i_a_l_o_g_:_:_s_e_t_T_e_x_t_(_)_ setText() is a new function that allows setting an initial value in the prompt dialog's text field. 3.2.5 _N_e_w__c_l_a_s_s__-__V_k_V_i_s_u_a_l VkVisual is a new class that simplifies applications' dealing X11 visuals. It is now easy to do such things as: +o Semantically choose the best visual for an application. +o Control interactions between widgets and X visuals. +o Get a suitable window for creating a GC or a pixmap. 3.2.6 _V_i_e_w_K_i_t__V_i_s_u_a_l__H_a_n_d_l_i_n_g__I_m_p_r_o_v_e_m_e_n_t_s 3.2.6.1 _V_i_s_u_a_l_s__B_u_g_s__h_a_v_e__B_e_e_n__F_i_x_e_d ViewKit itself has taken advantage of VkVisual to fix a number of visuals shortcomings. We known of no remaining bugs in ViewKit's handling of visuals. 3.2.6.2 _V_i_s_u_a_l_s__A_r_e__C_o_n_i_s_t_e_n_t_l_y__I_n_h_e_r_i_t_e_d ViewKit now automatically defaults to properly inheriting visual information from the widget parent for all Shell widgets it creates. ViewKit also automatically uses the correct depth when doing such things as creating GC's and pixmaps (including those routines that call Xpm). Note: libXpm itself has not been changed - it remains up to the caller take care of any visuals issues. 3.2.6.3 _A_d_d_i_t_i_o_n_a_l__C_o_n_s_t_r_u_c_t_o_r__f_o_r__V_k_A_p_p__T_a_k_e_s__a_n__A_r_g_L_i_s_t This is to allow an application to set the top-level shell's resources. Unfortunately, the visual resource cannot set this way, because the Display is not yet known. For a solution to that, see the next section. - 4 - 3.2.6.4 _P_u_t_t_i_n_g _A_n _E_n_t_i_r_e _A_p_p_l_i_c_a_t_i_o_n _I_n _a _N_o_n-_D_e_f_a_u_l_t _V_i_s_u_a_l Since the Display cannot be known before the call to VkApp::run(), a new feature has been added - the application can supply a preRealizeFunction(). This function, if present, is called just before VkApp is going to realize the application's top-level window. By that time the VkApp class has been constructed, and the Display is known. The application can then set the top level Shell's visual resources, either by using the new class VkVisual, or otherwise. This makes it easy to put an entire application into a non-default visual, such as 24-bit TreuColor. Alternatively, one can use "useOverlayApps" to put the application in the deepest available overlay visual. How good an idea this is depends in part on how deep the deepest overlay visual is. See _m_a_n _V_k_A_p_p for details. 3.2.6.5 _M_e_n_u_s__i_n__t_h_e__O_v_e_r_l_a_y_s How good an idea this is depends in part on how deep the deepest overlay visual is. As of IRIX 6.2 (ViewKit 1.4), the resource "useOverlayMenus" put pulldown menus in the 2-bit popup planes. It now puts all menus created by ViewKit in the deepest available overlay visual. Using the deepest available overlay visual helps if menus have colorful things, such as checkmarks. (The application remains responsible for the visual information for any menus it creates directly, rather than by using ViewKit.) 3.2.6.5.1 _D_e_m_o _P_r_o_g_r_a_m _F_o_r _P_u_l_l_d_o_w_n _M_e_n_u_s _I_n _T_h_e _P_o_p_u_p _P_l_a_n_e_s Running the example program "vkmenu" shows that the expose counter increments each time a menubar item is selected and dismissed. Running "vkmenu -useOverlayMenus" shows that the expose counter does not change when pulldown menus appear and disappear, since no expose events are generated. +o For more information about the demo program, see /_u_s_r/_s_h_a_r_e/_s_r_c/_V_i_e_w_K_i_t/_M_e_n_u_s/_R_E_A_D_M_E. +o For more information about the affected ViewKit classes, see _m_a_n _V_k_A_p_p(_3_X), _m_a_n _V_k_M_e_n_u(_3_X), _m_a_n _V_k_S_u_b_M_e_n_u(_3_X). - 5 - 3.2.6.6 _D_i_a_l_o_g_s__i_n__t_h_e__O_v_e_r_l_a_y_s There is a new resource, "useOverlayDialogs", that puts all dialogs created by ViewKit into the overlay planes. How good an idea this is depends in part on how deep the deepest overlay visual is. (The application remains responsible for the visual information for any dialogs it creates directly, rather than by using ViewKit.) There is no way for an application to specify creation-time arguments with the standard ViewKit dialog API. Two functions have been added to allow setting them before the first dialog is created: setArgs() and setVisual(). For more information a see _m_a_n _V_k_D_i_a_l_o_g_M_a_n_a_g_e_r(_3_X). _I_n _t_h_e _p_a_s_t, _a_n_y _V_i_e_w_K_i_t _a_p_p_l_i_c_a_t_i_o_n _h_a_d _t_o _l_i_n_k _w_i_t_h _s_o_m_e _h_e_l_p _l_i_b_r_a_r_y. _l_i_b_v_k_h_e_l_p _h_a_d _t_o _b_e _l_i_n_k_e_d _i_f _n_o _o_t_h_e_r _o_n_e _w_a_s. _N_o_w _t_h_e _c_o_n_t_e_n_t_s _o_f _t_h_e _d_e_f_a_u_l_t _h_e_l_p _l_i_b_r_a_r_y, _l_i_b_v_k_h_e_l_p, _h_a_v_e _b_e_e_n _m_o_v_e_d _i_n_t_o _l_i_b_v_k. _T_h_e _d_e_f_a_u_l_t _h_e_l_p _e_n_t_r_y _p_o_i_n_t_s _a_r_e _w_e_a_k _s_y_m_b_o_l_s. _T_h_i_s _m_e_a_n_s: +o _I_t _i_s _n_o _l_o_n_g_e_r _m_a_n_d_a_t_o_r_y _t_o _l_i_n_k _w_i_t_h _a_n_y _h_e_l_p _l_i_b_r_a_r_y. _I_f _y_o_u _d_o _n_o_t, _y_o_u _w_i_l_l _a_u_t_o_m_a_t_i_c_a_l_l_y _g_e_t _t_h_e _d_e_f_a_u_l_t _h_e_l_p _f_a_c_i_l_i_t_y. +o _S_o _t_h_a_t _e_x_i_s_t_i_n_g _M_a_k_e_f_i_l_e_s _w_i_l_l _n_o_t _b_r_e_a_k, _l_i_b_v_k_h_e_l_p _i_s _s_t_i_l_l _p_r_o_v_i_d_e_d, _b_u_t _o_n_l_y _a_s _a _n_u_l_l _l_i_b_r_a_r_y. _S_i_n_c_e _l_i_b_v_k_h_e_l_p _i_s _n_o _l_o_n_g_e_r _n_e_e_d_e_d, _i_t _s_h_o_u_l_d _b_e _r_e_m_o_v_e_d _f_r_o_m _l_i_n_k _l_i_n_e_s. _L_i_n_k_i_n_g _w_i_t_h _i_t _i_s _h_a_r_m_l_e_s_s, _b_u_t _d_o_e_s _p_u_t _a_n _u_n_n_e_c_e_s_s_a_r_y _i_t_e_m _o_n _t_h_e _a_p_p_l_i_c_a_t_i_o_n'_s _l_i_b_l_i_s_t. +o _L_i_n_k_i_n_g _w_i_t_h _a_n_y _o_t_h_e_r _h_e_l_p _l_i_b_r_a_r_y _i_s _u_n_c_h_a_n_g_e_d. _S_i_n_c_e _t_h_e _s_y_m_b_o_l_s _i_n _t_h_e _d_e_f_a_u_l_t _l_i_b_r_a_r_y _a_r_e _n_o_w _w_e_a_k _s_y_m_b_o_l_s, _t_h_e _e_x_p_l_i_c_i_t_l_y _l_i_n_k_e_d _l_i_b_r_a_r_y _w_i_l_l _b_e _t_h_e _o_n_e _t_h_a_t _i_s _u_s_e_d. +o _I_f _y_o_u _l_i_n_k _w_i_t_h _a _h_e_l_p _l_i_b_r_a_r_y, _a_n_d _i_f _y_o_u_r _u_s_e _t_h_e -_q_u_i_c_k_s_t_a_r_t__i_n_f_o _s_w_i_t_c_h, _y_o_u _m_a_y _s_e_e _w_a_r_n_i_n_g_s _f_r_o_m _l_d(_1) _a_b_o_u_t _t_h_e _h_e_l_p _e_n_t_r_y _p_o_i_n_t_s (_S_G_I_H_e_l_p_I_n_i_t, _S_G_I_H_e_l_p_M_s_g, _S_G_I_H_e_l_p_I_n_d_e_x_M_s_g) _p_r_e-_e_m_p_t_i_n_g _t_h_o_s_e _i_n _l_i_b_v_k. _T_h_e_s_e _m_e_s_s_a_g_e_s _a_r_e _n_o_r_m_a_l. _T_h_e_y _w_i_l_l _n_o_t _a_p_p_e_a_r _u_n_l_e_s_s _y_o_u _u_s_e -_q_u_i_c_k_s_t_a_r_t__i_n_f_o. _T_h_e_r_e _i_s _a _n_e_w _h_e_l_p _l_i_b_r_a_r_y, _l_i_b_v_k_w_e_b_h_e_l_p. _3._2._7 _S_u_p_p_o_r_t__f_o_r__C_o_n_t_r_o_l_l_i_n_g__W_i_d_t_h__o_f__T_a_b_s__i_n__a__T_a_b_P_a_n_e_l We have had several requests for providing a way to have tabs in different tab decks all have the same tab width. We have added several new functions to VkTabPanel to provide this. - 6 - +o ggggeeeettttTTTTaaaabbbbWWWWiiiiddddtttthhhh(((()))) - gets the width of a specific tab. +o ggggeeeettttMMMMaaaaxxxxTTTTaaaabbbbWWWWiiiiddddtttthhhh(((()))) - gets the width of the widest tab. +o mmmmaaaattttcccchhhhTTTTaaaabbbbWWWWiiiiddddtttthhhh (((()))) - makes the width of the labels in two or more VkTabPanels be the same. +o sssseeeettttTTTTaaaabbbbWWWWiiiiddddtttthhhh(((()))) - sets the with of the tabs in a single tab panel. There is also a demo, ////uuuussssrrrr////sssshhhhaaaarrrreeee////ssssrrrrcccc////VVVViiiieeeewwwwKKKKiiiitttt////CCCCoooommmmppppoooonnnneeeennnnttttssss////ttttaaaabbbb....cccc++++++++. Read the source -- there are several comments about the new calls. By reading the comments and playing around with the code, you should be able to easily make it all work for you. 3.2.8 _N_e_w__m_a_c_r_o___f_a_m_i_l_y__V_k_A_s_s_e_r_t_* Macros have been added to give increased control over assertions in your code. See _m_a_n _V_k_A_s_s_e_r_t and _V_k/_V_k_F_u_n_c_t_i_o_n._h>. 4. _O_v_e_r_v_i_e_w__o_f__t_h_e__I_R_I_X__6_._2__r_e_l_e_a_s_e +o n32 and 64-bit libraries are now provided. +o Debug library naming has been changed to make the debug libraries much easier to use. To use a debugging version of the ViewKit libraries, install the ViewKit_dev.sw.debug, and then simply set the LLLLDDDD____LLLLIIIIBBBBRRRRAAAARRRRYYYY____PPPPAAAATTTTHHHH environment variable to /usr/lib/debug before running your program. The debugging library has full symbols, so stack traces will be more informative. The debugging viewkit library also prints various warnings, and makes liberal use of assertions to catch misuse of the the library. +o To allow for future versioning, libXpm.so has been renamed to libXpm.so.1, and libXpm.so is now a symbolic link to libXpm.so.1. +o libXpm is now version 3.4f (previously it was version 3.2g). - 7 - 4.1 _V_i_e_w_K_i_t__B_u_g__F_i_x_e_s This chapter lists the major bugs fixed in ViewKit since the IRIX 5.3 release. +o Corrected a number of references to the default colormap to use the correct colormap. +o We have made a systematic effort, using _p_u_r_i_f_y, to find and fix memory leaks. All known ViewKit-induced memory leaks and malloc problems have been fixed. +o _V_k_F_i_l_e_S_e_l_e_c_t_i_o_n_D_i_a_l_o_g can now set a filter on multiple dialogs. +o _V_k_C_o_m_p_o_n_e_n_t::_a_f_t_e_r_R_e_a_l_i_z_e_H_o_o_k now gets called for dialogs. +o The file selection dialog now sets its directory correctly, even if there is more than one file selection dialog up at a time. +o Several manual page errors and omissions have been fixed. +o Several classes that did not have manual pages now have them. +o Several schemes problems have been corrected. +o _V_k_C_o_m_p_o_n_e_n_t now calls afterRealizeHook(), even if the parent is already realized when show() is called. +o _V_k_D_o_u_b_l_e_B_u_f_f_e_r now draws the initial display correctly, even if it was not realized when it was drawn. +o _V_k_F_o_r_k_I_O::_c_l_e_a_r_H_i_s_t_o_r_y no longer goes into an infinite loop. +o _V_k_G_r_a_p_h now returns the correct node after a node is removed. +o _V_k_G_r_a_p_h now passes back the X event where appropriate and it has an event. +o Menu items are now in right place when addAction called after menu built. +o Initial menu pane hide now works. - 8 - +o Option menu getIndex() now returns 0 initially, not -1. +o _V_k_N_L_S no longer puts up an empty dialog if no resource string is set. +o Fixed the core dump in _V_k_T_a_b_P_a_n_e_l when adding or deleting tabs. +o _V_k_T_a_b_P_a_n_e_l's popup menu can no longer be torn off -- doing so was a problem. +o Fixed the core dump when _V_k_T_a_b_P_a_n_e_l was deleted while a work proc was pending. +o Set the background of the _V_k_T_a_b_P_a_n_e_l drawing area to eliminate color flashing. +o xpm.h is now installed in /usr/include/X11, where most applications expect it. To maintain compatibility with IRIX 5.3 and earlier, there is with a symlink from /usr/include/Vk. +o Xpm has been upgraded to xpm version 3.4. This fixes some core dumps. +o _V_k_C_r_e_a_t_e_X_P_M_P_i_x_m_a_p now handles non-default Visuals correctly. +o Changed demo file installation to be owner=root, group=sys, modes 755(directories) and 644(files. This change was in deference to those who felt that looser permissions presented a security problem. 4.2 _n_3_2__a_n_d__6_4_-_b_i_t__l_i_b_r_a_r_i_e_s n32 versions of all ViewKit libraries are provided in /usr/lib32. 64-bit versions of all ViewKit libraries are provided in /usr/lib64. For instructions on building the ViewKit demo programs in either n32 or 64-bits, see the top-level README and Makefile. - 9 - 4.3 _D_e_b_u_g__l_i_b_r_a_r_i_e_s__h_a_v_e__b_e_e_n__r_e_n_a_m_e_d__f_o_r__e_a_s_i_e_r__u_s_e There are no more ViewKit *_d.a debug libraries, requiring relinking your application to use them. Debug libraries are now DSO's that are installed in the debug subdirectory below the corresponding normal DSO. The library names are identical. This means that an application can link normally, rather than with a special debug library. By setting the environment variable LLLLDDDD____LLLLIIIIBBBBRRRRAAAARRRRYYYY____PPPPAAAATTTTHHHH, the application can run with the debug library. For example, to run with the 64-bit debug libraries, just: +o Link normally, such as with "-L/usr/lib64 -lvk". +o When you want to run with the debug libraries, set the environment variable LLLLDDDD____LLLLIIIIBBBBRRRRAAAARRRRYYYY____PPPPAAAATTTTHHHH to /usr/lib64/debug. As always, the debug libraries have a number of aaaasssssssseeeerrrrtttt statements. These are intended to check both the application's use of the library and internal library consistency. The assertions are not as complete as we would like, but we are adding more over time. 4.4 _C_l_a_s_s__E_n_h_a_n_c_e_m_e_n_t_s We have been very careful to maintain binary compatibility when enhancing a class. Some changes introduce entirely new, non-conflicting, behavior for the class. Other changes introduce a choice between a new behavior and the way the class has behaved in the past. In such a case, to preserve compatibility, the default remains to run the old way. An application has to do something, such as set a resource, to get the new behavior. 4.4.1 _V_k_A_p_p__E_n_h_a_n_c_e_m_e_n_t_s For more information about any of these enhancements, see _m_a_n _V_k_A_p_p(_3_X). 4.4.1.1 _V_k_A_p_p_:_:_r_u_n_(_) There is a new debugging resource, _p_r_i_n_t_E_v_e_n_t. If set non-zero, all events are printed to stderr. _V_k_A_p_p::_r_u_n and _V_k_A_p_p:_h_a_n_d_l_e_P_e_n_d_i_n_g_E_v_e_n_t_s() now have increased event-handling flexibility. They now allow the application more control over how the X event loop is handled, without the need to override the ViewKit routine. - 10 - Until now overriding _V_k_A_p_p::_r_u_n() has been dangerous (because of potential compatibility problems). It continues to be the case that very few applications have a legitimate need to override _V_k_A_p_p::_r_u_n(). However, there is now a safe way for those applications that _d_o have this need to do so. See the following topics in the VkApp(3) manual page: _r_u_n(), _r_u_n__f_i_r_s_t(), _r_u_n_O_n_e_E_v_e_n_t(), _h_a_n_d_l_e_P_e_n_d_i_n_g_E_v_e_n_t_s, and _h_a_n_d_l_e_O_n_e_P_e_n_d_i_n_g_E_v_e_n_t. There is a new demo program that shows the improved event handling. See /_u_s_r/_s_h_a_r_e/_s_r_c/_V_i_e_w_K_i_t/_B_a_s_i_c/_r_u_n._c++. Running this program will clearly show which code is doing what art of the job. 4.4.1.2 _V_k_A_p_p_:_:_u_s_e_S_c_h_e_m_e_s_(_) The static function _V_k_A_p_p::_u_s_e_S_c_h_e_m_e_s(_c_h_a_r *_v_a_l) has been added to let schemes be turned on or off programmatically. Schemes defaults to being on. For example, +o uuuusssseeeeSSSScccchhhheeeemmmmeeeessss((((""""aaaallllllll"""")))) will turn schemes on +o uuuusssseeeeSSSScccchhhheeeemmmmeeeessss((((""""nnnnoooonnnneeee"""")))) will turn schemes off 4.4.1.3 _N_e_w__r_e_s_o_u_r_c_e_:__q_u_i_t_M_o_d_e _q_u_i_t_M_o_d_e is a new string- valued resource (default value: eeeeaaaacccchhhh). _V_k_A_p_p::_q_u_i_t_Y_o_u_r_s_e_l_f() calls _o_k_T_o_Q_u_i_t for each window. In the past (and still true by default) if any of them returns success, then the application quits. If, however, _q_u_i_t_M_o_d_e is set to aaaallllllll then the application quits if, and only if, all windows agree to. _N_O_T_E: _t_h_i_s _d_o_e_s _n_o_t _a_p_p_l_y _w_h_e_n _t_h_e _w_i_n_d_o_w _m_a_n_a_g_e_r _t_r_i_e_s _t_o _c_l_o_s_e _a _w_i_n_d_o_w. _T_o _c_o_n_t_r_o_l _t_h_a_t _b_e_h_a_v_i_o_r, _a_n _a_p_p_l_i_c_a_t_i_o_n _m_u_s_t _o_v_e_r_r_i_d_e VkSimpleWindow::handleWmDeleteMessage() _a_n_d/_o_r VkSimpleWindow::handleWmQuitMessage(). _F_r_o_m _t_h_e_r_e, _t_h_e _a_p_p_l_i_c_a_t_i_o_n _c_a_n _c_a_l_l VkApp::quitYourself() _i_f _i_t _w_a_n_t_s _t_o. 4.4.1.4 _V_k_A_p_p_:_:_s_e_t_F_a_l_l_b_a_c_k_s_(_) _s_t_a_t_i_c _v_o_i_d _V_k_A_p_p::_s_e_t_F_a_l_l_b_a_c_k_s(_c_h_a_r **_f_a_l_l_b_a_c_k_s) sets _f_a_l_l_b_a_c_k_s as the _s_p_e_c_i_f_i_c_a_t_i_o_n__l_i_s_t needed to call _X_t_A_p_p_S_e_t_F_a_l_l_b_a_c_k_R_e_s_o_u_r_c_e_s(_3_X). - 11 - 4.4.2 _V_k_C_o_m_p_o_n_e_n_t__E_n_h_a_n_c_e_m_e_n_t_s For more information about any of these enhancements, see _m_a_n _V_k_C_o_m_p_o_n_e_n_t(_3_X). 4.4.2.1 _V_k_C_o_m_p_o_n_e_n_t_:_:_l_o_a_d_O_b_j_e_c_t_(_) _s_t_a_t_i_c _V_k_C_o_m_p_o_n_e_n_t *_l_o_a_d_O_b_j_e_c_t(_c_o_n_s_t _c_h_a_r *_n_a_m_e, _W_i_d_g_e_t _p_a_r_e_n_t, _c_o_n_s_t _c_h_a_r *_c_l_a_s_s_N_a_m_e, _c_o_n_s_t _c_h_a_r *_f_i_l_e_n_a_m_e) supports dynamic loading of objects, as supported by RapidApp. Objects must be set up properly for this to work. See _m_a_n _V_k_C_o_m_p_o_n_e_n_t and _m_a_n _V_k_C_a_l_l_b_a_c_k_O_b_j_e_c_t or the RapidApp documentation for details. 4.4.2.2 _V_k_C_o_m_p_o_n_e_n_t_:_:_s_e_t_D_e_f_a_u_l_t_R_e_s_o_u_r_c_e_s_(_) _v_o_i_d _V_k_C_o_m_p_o_n_e_n_t::_s_e_t_D_e_f_a_u_l_t_R_e_s_o_u_r_c_e_s ( _c_o_n_s_t _W_i_d_g_e_t _w, _c_o_n_s_t _S_t_r_i_n_g *) now supports a syntax (a prepended "+" or "-") that qualifies resources for such things as overriding SGI Schemes. 4.4.3 _V_k_D_i_a_l_o_g_M_a_n_a_g_e_r_:_:_p_r_e_p_o_s_t_C_a_l_l_b_a_c_k This callback is invoked just before a dialog is displayed. For more information see _m_a_n _V_k_D_i_a_l_o_g_M_a_n_a_g_e_r(_3_X). 4.4.4 _V_k_D_i_a_l_o_g_M_a_n_a_g_e_r_:_:_e_n_a_b_l_e_C_a_n_c_e_l_B_u_t_t_o_n_(_B_o_o_l_e_a_n_) This sets whether or not the default will be to provide a CANCEL button on dialogs that are subsequently posted. It allows an application to tell when a dialog was closed without pressing a button, such as by a window manager action. For more information see _m_a_n _V_k_D_i_a_l_o_g_M_a_n_a_g_e_r(_3_X). 4.4.5 _V_k_M_e_n_u__E_n_h_a_n_c_e_m_e_n_t_s For more information about any of these enhancements, see _m_a_n _V_k_M_e_n_u(_3_X). 4.4.5.1 _V_k_M_e_n_u_:_:_s_e_t_M_e_n_u_B_a_r__(_) _V_k_M_e_n_u::_s_e_t_M_e_n_u_B_a_r (_V_k_M_e_n_u_D_e_s_c *_m_e_n_u_D_e_s_c, _X_t_P_o_i_n_t_e_r _c_l_i_e_n_t_D_a_t_a) is an overloaded entry to allow controlling default client data. This effectively allows passing zero as client data (by setting the default client data to zero). There remains no way to tell passing an explicit zero from just not initializing the client data in the _V_k_M_e_n_u_D_e_s_c structure. 4.4.5.2 _V_k_M_e_n_u_:_:_g_e_t_L_a_b_e_l__(_) _V_k_M_e_n_u_I_t_e_m::_g_e_t_L_a_b_e_l(_v_o_i_d) was added for symmetry with the existing _V_k_M_e_n_u_I_t_e_m::_s_e_t_L_a_b_e_l(). - 12 - 4.4.5.3 _V_k_M_e_n_u__s_e_p_a_r_a_t_o_r_s__c_a_n__n_o_w__h_a_v_e__n_a_m_e_s Menu separators can now have names. This is so that they can be manipulated just like any other menu item. 4.4.6 _V_k_M_e_n_u_B_a_r_:_:_s_h_o_w_H_e_l_p_P_a_n_e_(_) _V_k_M_e_n_u_B_a_r::_s_h_o_w_H_e_l_p_P_a_n_e(_B_o_o_l_e_a_n _s_h_o_w = _T_R_U_E) controls whether the Help pane is visible or not. For more information see _m_a_n _V_k_M_e_n_u_B_a_r(_3_X). 4.4.7 _V_k_N_a_m_e_L_i_s_t__E_n_h_a_n_c_e_m_e_n_t_s For more information about any of these enhancements, see _m_a_n _V_k_N_a_m_e_L_i_s_t(_3_X). 4.4.7.1 _V_k_N_a_m_e_L_i_s_t__h_a_s__n_e_w__m_e_m_b_e_r__f_u_n_c_t_i_o_n_s Some new utility functions have been added. +o _V_k_N_a_m_e_L_i_s_t::_g_e_t_I_n_d_e_x(); +o _V_k_N_a_m_e_L_i_s_t::_r_e_m_o_v_e(_c_h_a_r *); +o _V_k_N_a_m_e_L_i_s_t::_r_e_m_o_v_e(_i_n_t _i_n_d_e_x, _i_n_t _c_o_u_n_t=_1); 4.4.7.2 _P_r_o_b_l_e_m__w_i_t_h__V_k_N_a_m_e_L_i_s_t__o_p_e_r_a_t_o_r_s Some of the _V_k_N_a_m_e_L_i_s_t operators are a problem, because they allocate memory that must later be freed by the caller. Because operators are often used in expressions, this is an open invitation to memory leaks. Several corresponding new conventional functions have been added. They each make it more obvious that there might be something to be freed. One of them (_g_e_t_S_u_b_s_t_r_i_n_g_s()) is also considerably more efficient. Applications are strongly encouraged to switch to the new conventional functions. +o _V_k_N_a_m_e_L_i_s_t::_g_e_t_S_t_r_i_n_g(); +o _V_k_N_a_m_e_L_i_s_t::_g_e_t_S_u_b_s_t_r_i_n_g_s(); +o _V_k_N_a_m_e_L_i_s_t::_g_e_t_S_t_r_i_n_g_T_a_b_l_e(); +o _V_k_N_a_m_e_L_i_s_t::_g_e_t_X_m_S_t_r_i_n_g_T_a_b_l_e() +o _V_k_N_a_m_e_L_i_s_t::_f_r_e_e_X_m_S_t_r_i_n_g_T_a_b_l_e() 4.4.8 _V_k_R_u_n_O_n_c_e_2__n_o_t_e For more information about _V_k_R_u_n_O_n_c_e or _V_k_R_u_n_O_n_c_e_2, see _m_a_n _V_k_R_u_n_O_n_c_e(_3_X) and _m_a_n _V_k_R_u_n_O_n_c_e_2(_3_X). - 13 - _V_k_R_u_n_O_n_c_e_2 is very similar to _V_k_R_u_n_O_n_c_e, but there are subtle differences between these two classes. _V_k_R_u_n_O_n_c_e_2 adds several new member functions. It also does error checking that _V_k_R_u_n_O_n_c_e does not. We suggest that all applications that can do so use _V_k_R_u_n_O_n_c_e_2, rather than _V_k_R_u_n_O_n_c_e. 4.4.9 _V_k_S_i_m_p_l_e_W_i_n_d_o_w__E_n_h_a_n_c_e_m_e_n_t_s For more information about any of these enhancements, see _m_a_n _V_k_S_i_m_p_l_e_W_i_n_d_o_w(_3_X). 4.4.9.1 _V_k_S_i_m_p_l_e_W_i_n_d_o_w__p_r_o_v_i_d_e_s__a_c_c_e_s_s__t_o__Q_u_i_c_k_H_e_l_p QuickHelp provides a status line at the bottom of the window and/or a popup balloon help. The feature is controlled by X resources, so all that is needed to enable it for any particular application is the right settings in the application's X default resources file. Note: There is also an experimental programmatic interface to QuickHelp. _T_h_i_s _i_n_t_e_r_f_a_c_e, _n_e_w _i_n _I_R_I_X _6._2, _i_s _s_u_b_j_e_c_t _t_o _c_h_a_n_g_e _i_n _a _f_u_t_u_r_e _r_e_l_e_a_s_e. _d_i_s_p_l_a_y_H_e_l_p_S_t_r_i_n_g(...) and _d_i_s_p_l_a_y_H_e_l_p_R_e_s_o_u_r_c_e(...) have had their final argument changed in a completely compatible way. It was a Boolean, where FALSE meant no delay and TRUE meant to use the default delay. Now it is of type _d_e_l_a_y_T_i_m_e, which for compatibility is typdef'd to be the same as a Boolean. This takes the popup delay time in hundredths of a second. This ranges from 0-255, except that for compatibility 1 means to use the default time. 4.4.9.2 _V_k_S_i_m_p_l_e_W_i_n_d_o_w_:_:_g_e_t_W_i_n_d_o_w_(_) _s_t_a_t_i_c _V_k_S_i_m_p_l_e_W_i_n_d_o_w *_g_e_t_W_i_n_d_o_w(_V_k_C_o_m_p_o_n_e_n_t *_c_o_m_p_o_n_e_n_t) returns the _V_k_S_i_m_p_l_e_W_i_n_d_o_w object (or subclass) that contains the given _V_k_C_o_m_p_o_n_e_n_t. 4.4.10 _V_k_T_a_b_P_a_n_e_l__I_m_p_r_o_v_e_d__A_p_p_e_a_r_a_n_c_e _V_k_T_a_b_P_a_n_e_l previously had a flat appearance for its tabs, rather than providing tabs with a shaded 3D appearance. This was considered more of a bug to be fixed than a feature. _V_k_T_a_b_P_a_n_e_l tab drawing has now been improved so that the tabs have an (optional) 3D appearance. The new 3D appearance is controlled by a new _V_k_T_a_b_P_a_n_e_l resource, _u_s_e_3_D_T_a_b_s (default TRUE). If the resource is set to TRUE, the tabs are drawn with a shaded 3D appearance. - 14 - _V_k_T_a_b_P_a_n_e_l also has two new member functions so that applications can cooperate with the improved (fixed) appearance. Applications that construct pixmaps for tab labels should set _u_s_e_3_D_T_a_b_s = _T_R_U_E and use the new functions to get their backgrounds. +o Pixel getSelectedTabBG() +o Pixel getUnselectedTabBG() The member function GC gc() is now deprecated, in favor of the new functions, because it is meaningful only with _u_s_e_3_D_T_a_b_s = _F_A_L_S_E. Apps that construct pixmaps for tab labels should set _u_s_e_3_D_T_a_b_s = _T_R_U_E and use the new functions to get their backgrounds. For more information see _m_a_n _V_k_T_a_b_P_a_n_e_l(_3_X). 4.4.11 _V_k_W_i_n_d_o_w__E_n_h_a_n_c_e_m_e_n_t_s For more information about any of these enhancements, see _m_a_n _V_k_W_i_n_d_o_w(_3_X). 4.4.11.1 _V_k_W_i_n_d_o_w_:_:_g_e_t_W_i_n_d_o_w_(_) _s_t_a_t_i_c _V_k_W_i_n_d_o_w *_g_e_t_W_i_n_d_o_w(_V_k_C_o_m_p_o_n_e_n_t *_c_o_m_p_o_n_e_n_t) returns the _V_k_W_i_n_d_o_w object (or subclass) that contains the given _V_k_C_o_m_p_o_n_e_n_t. 4.4.11.2 _V_k_W_i_n_d_o_w_:_:_g_e_t_M_e_n_u_(_) _s_t_a_t_i_c _V_k_M_e_n_u_B_a_r *_g_e_t_M_e_n_u(_V_k_C_o_m_p_o_n_e_n_t *_c_o_m_p_o_n_e_n_t) returns the menubar used by the window that contains the given _V_k_C_o_m_p_o_n_e_n_t. 4.5 _N_e_w__C_l_a_s_s_e_s The following classes are new since IRIX 5.3. 4.5.1 _V_k_C_o_l_o_r_C_h_o_o_s_e_r_D_i_a_l_o_g For more information, see _m_a_n _V_k_C_o_l_o_r_C_h_o_o_s_e_r_D_i_a_l_o_g(_3_X). 4.5.2 _V_k_C_u_t_P_a_s_t_e The _V_k_C_u_t_P_a_s_t_e class provides programmers with a simple and clean API for implementing cut and paste and drag and drop functionality in their application. For more information, see _m_a_n _V_k_C_u_t_P_a_s_t_e(_3_X). - 15 - 4.5.3 _V_k_M_o_v_i_e_B_u_t_t_o_n _V_k_M_o_v_i_e_B_u_t_t_o_n is a multimedia button component that plays a movie within a pushable button. This class is most effective with a short movie that acts as an animation. For more information, see _m_a_n _V_k_M_o_v_i_e_B_u_t_t_o_n(_3_X). 4.5.4 _V_k_M_o_v_i_e_P_l_a_y_e_r _V_k_M_o_v_i_e_P_l_a_y_e_r is a multimedia component that plays a movie and supports simple operations such as playing, stopping, rewinding. For more information, see _m_a_n _V_k_M_o_v_i_e_P_l_a_y_e_r(_3_X). 4.5.5 _V_k_P_r_o_g_r_e_s_s_D_i_a_l_o_g This is a new SGI Style Guide- compliant class for displaying the approximate amount of a task that has been completed. For more information, see _m_a_n _V_k_P_r_o_g_r_e_s_s_D_i_a_l_o_g(_3_X). 4.5.6 _V_k_S_o_A_p_p _V_k_S_o_A_p_p is a class used by all Inventor ViewKit applications to handle initialization. For more information, see _m_a_n _V_k_S_o_A_p_p(_3_X). 4.5.7 _V_k_T_a_b_b_e_d_D_e_c_k _V_k_T_a_b_b_e_d_D_e_c_k combines a _V_k_T_a_b_P_a_n_e_l and a _V_k_D_e_c_k, to give an appearance somewhat like a set of tabbed cards. For more information, see _m_a_n _V_k_T_a_b_b_e_d_D_e_c_k(_3_X). 4.6 _N_e_w__G_l_o_b_a_l__F_u_n_c_t_i_o_n_s The following global functions are new since IRIX 5.3. 4.6.1 _V_k_S_e_t_H_i_g_h_l_i_g_h_t_i_n_g_P_i_x_m_a_p For more information, see _m_a_n _V_k_S_e_t_H_i_g_h_l_i_g_h_t_i_n_g_P_i_x_m_a_p(_3_X). 4.6.2 _V_k_C_o_n_f_i_g_u_r_e_W_i_n_d_o_w For more information, see _m_a_n _V_k_C_o_n_f_i_g_u_r_e_W_i_n_d_o_w(_3_X). - 16 - 4.7 _N_e_w__l_i_b_r_a_r_y_:__l_i_b_v_k_S_G_I libvk is a portable library. There are versions available for most Unix workstations. libvkSGI has been created for classes that philosophically belong in libvk, but which are SGI-specific. In this release, libvkSGI includes: 4.8 _N_e_w__l_i_b_r_a_r_y_:__l_i_b_V_k_E_Z_._a 4.9 _l_i_b_X_p_m__u_p_g_r_a_d_e_s 4.9.1 _X_p_m__d_o_c_u_m_e_n_t_a_t_i_o_n We now pass through the documentation files that we get with Xpm. These files are shipped as the subsystem _V_i_e_w_K_i_t__d_e_v._m_a_n._x_p_m-_d_o_c, and are installed in /usr/share/doc/Xpm. The new on-line _X_p_m(_3_x) man page also tells where to find these documents. 4.9.2 _l_i_b_X_p_m_._s_o__h_a_s__b_e_c_o_m_e__l_i_b_X_p_m_._s_o_._1 To provide for future incompatible libXpm DSO's, libXpm.so is now called libXpm.so.1. There is a symbolic link, libXpm.so, that points to libXpm.so.1. This should cause no problems for any existing application. 4.9.3 _l_i_b_X_p_m__i_s__n_o_w__v_e_r_s_i_o_n__3_._4 The IRIX 5.3 release contained Xpm version 3.2g. SGI never released Xpm version 3.3, which was incompatible with 3.2. The current release is Xpm 3.4, which is both source and binary compatible with Xpm version 3.2. 4.9.4 _X_p_m__E_n_h_a_n_c_e_m_e_n_t_s__S_i_n_c_e__I_R_I_X__5_._3__(_X_p_m__3_._2_g_) +o The colorTable member of the XpmAttributes structure is now an (XpmColor*) in order to be compatible with an XpmImage colorTable. However in order to be backward compatible this field is cast to (XpmColor **), which is equivalent to (char ***), when it is used with the old flags XpmInfos and XpmReturnInfos. To handle the new type, the new flags XpmColorTable and XpmReturnColorTable have been defined. NOTE: code that directly accesses the XpmAttributes.colorTable, such as "... = - 17 - XpmAttributes.colorTable[i][1]" will need to be changed to something like "... = XpmAttributes.colorTable[i].symbolic" +o The XpmInfo struct has been extended to avoid having to deal with an XpmAttributes at the lower level. The idea is that all the data stored in an Xpm file can be retrieved through both an XpmImage and an XpmInfo struct. +o XpmUndefPixel is defined and exported by xpm.h in order to let clients providing their own colorTable when writing out an Xpm file. +o A new function and a new define should help client figuring out with which Xpm library version they are working. These are XpmIncludeVersion and XpmLibraryVersion(). +o XPM1 files are supported. +o A new function is provided to get an error string related to the returned error code. +o The parser is more flexible about the way strings are distributed on lines. A single line XPM file can be read. +o A new level interface is provided to allow applications to do either icon editing or data caching. +o New structures are provided to deal with the lower level: XpmImage, XpmColor, XpmInfos. +o xpm.h defines XpmFormat, XpmVersion, and XpmRevision numbers. 4.9.5 _X_p_m__B_u_g__F_i_x_e_s__S_i_n_c_e__I_R_I_X__5_._3 +o A segmentation fault occurring in some weird case. +o The list of pixels returned in XpmAttributes was wrong when two colors were defined as None in the read XPM. +o The parser was skipping white space reading extension strings. This has been fixed so extension lines are now returned exactly as they are. +o When writing an XPM file, '-' characters are replaced with '_' characters in the array name, in order to get - 18 - a valid C syntax name. +o XYPixmap format images are now handled correctly. +o XPM1 file with names using multiple '_' characters are now handled correctly. +o Reading certain binary files was leading to a bus error. +o The ? character is no longer used when writing an XPM file in order to avoid possible ANSI trigraphs. 
